Clients use distributed computer environments to perform a variety of tasks across multiple applications. In general, a client sends a request to an application server in a distributed computer environment. The application server is a computer acting as an intermediary between the client and other resources making up the distributed computer environment, and it may perform tasks such as verifying the client's security credentials and determining which resource on the distributed computer environment is appropriate for executing the client's request. The application server then forwards the request to the appropriate resource on behalf of the client. After the request executes on the appropriate resource, the application server sends the response to the client.
Fragment markup and assembly technologies known in the art allow for fragmentation of client requests at the application server. Requests are fragmented into multiple smaller tasks or “fetches” and are distributed across multiple resources for execution. Fragmentation allows for more efficient use of resources and for lower cycle-times on a distributed computer environment. After all of the fragments are executed, the responses to each fragment are aggregated.
However, if the fragments execute only in sequence, there can be a long delay from the time the request is made until the fragment responses are aggregated. To shorten this delay, methods have been developed for asynchronous execution of fragments. If the fragments can be executed in any order, including simultaneously, the overall execution time is reduced.
In some asynchronous fragment execution systems, the aggregation of the fragment responses takes place at the application server side, thus tying up application server system resources. In particular, the application server is tied up with the execution thread until the entire request is executed, thus delaying the delivery a of response to the client. To overcome this problem, systems have been developed for client-side aggregation of fragment responses. Such a system is disclosed in a U.S. patent application Ser. No. 11/846,423 owned by IBM (International Business Machines Corporation, Armonk, N.Y.). In that system, a new thread is created for the execution of each asynchronous include request from a client, and the asynchronous include for each request is registered with a results server. Asynchronous include content in the response provided to the client is replaced with javascript. After the client receives the response, the client runs the javascript which queries the results server for the asynchronous include results, which are then aggregated into the final response by the client.
For the sake of clarity, a simplified, generic version of this system is now discussed with reference to FIG. 1. Client 102, application server 104, results server 106, and private server 108 are connected by a network. Application server 104 and results server 106 are public servers that may be directly accessed by client 102. Data from private server 108 is indirectly accessible by client 102 via results server 106.
Client 102 makes a request 110 to application server 104, the request containing one or more asynchronous includes. Application server 104 executes the asynchronous include from the request, and registers 115 the request with results server 106. Application server 104 then prepares javascript that will eventually query results server 106 and aggregate at client 102 the asynchronous include content requested by client 102. Application server 104 then sends an initial response 120 back to client 102, the response containing the javascript and a unique identifier in place of the asynchronous include content requested. Application server 104 executes asynchronous includes 125 with private server 108, and publishes 130 the results at results server 106. The javascript now at client 102 then runs and queries 135 the results server 106 for the asynchronous include content initially requested by client 102. The asynchronous include content is then returned 140 to client 102 where it is aggregated to form the complete response initially requested 110 by client 102.
However, a problem with this approach is that not only must the requesting client be authorized to query results from the results server, but the querying client must also be verified as the same client that made the initial request to the application server. Although the problem of authorization may be solved with known methods, there is a need for a way to verify that the querying client is the same as the initial requesting client. Additionally, there is a need for a way for the querying client to verify that the results received from the result server are in fact being returned from the result server that is associated with the public server the client made the initial request to.